Payment vehicle with on and off functions

ABSTRACT

A computer-based network system and method for using a payment vehicle having an on and off function. The system comprises a payment vehicle comprising an on and off function to enable or to disable the payment vehicle in the computer-based network for processing an electronic payment transaction, a holder of the payment vehicle, and a computer payment network wherein the computer payment network comprises a transaction engine for enabling or for disabling the payment vehicle at a request of the holder of the payment vehicle.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of and claims priority from U.S.patent application Ser. No. 13/826,246, filed on Mar. 14, 2013, which isa divisional of U.S. patent application Ser. No. 12,316,996, filed onDec. 18, 2008, which claims priority from U.S. Provisional ApplicationSer. No. 61/197,872, filed on Oct. 31, 2008, the disclosures of whichare incorporated herein by their entireties.

BACKGROUND

The present invention relates to a payment vehicle having an on and offfunction for use in a computer-based network for processing electronicpayment transactions.

In today's payment environment, there are a very few number of paymenttransactions or other financial transactions that occur with cash. Mostpurchases occur with forms of payment other than cash using variouspayment instruments such as credit cards, debit cards, among others.Furthermore, there are an increasing number of payment transactions thatoccur electronically or via a web interface such as over the internet orworldwide web. With an increasing volume of transactions conducted withpayment instruments other than cash and often not by the purchaser inperson at point of sale, there is an increased likelihood of fraudulenttransactions and lack of personal control over the payment transaction.

Additionally, in today's payment environment, a payment instrument isalways turned “on” leading to abuse and fraud. Currently, a paymentvehicle can be blocked if a credit or debit card, for example, is lostor stolen by calling a customer service representative of the cardissuer after occurrence of the fraudulent event and requesting that thecard be canceled or blocked after the occurrence. There are numerousdisadvantages associated with such a process. For example, there may bea delay before a payment instrument holder even recognizes that afraudulent event occurred or is occurring using the payment holder'spayment instrument. There is also a real-time delay between when apayment instrument holder recognizes that there has been fraud or abuseassociated with its payment instrument and when the customer servicerepresentative is able to cancel or block the account. Fraudulent use ofa card can even occur while the customer service representative iscanceling or blocking the account associated with the payment vehicle.Thus, a payment holder does not have direct control and is limited bycurrently existing processes. Likewise, a payment instrument holder whodesires to make changes to its account does not have direct control todo so and also customarily relies upon a customer servicerepresentative.

With respect to misuse or fraudulent use of a payment instrument, thereare ways in today's existing payment systems to minimize fraud and abuseof the payment vehicle; however, they require assistance outside of thecontrol of the payment vehicle holder. For example, a credit or debitcard account can be closed, a temporary block can be placed on the card,or a country level block can be placed (for example, do not accept anycharges being made in a specified country). Unfortunately, such controlsare implemented after occurrence of the event.

Thus, there is a need to minimize the current risk to a holder of apayment instrument. There is also a need to find a way to shift controlof the payment instrument to the payment instrument holder as well as tomitigate abuse and fraud associated with unauthorized use of a paymentvehicle and the delays associated with mitigating such loss. There isalso a need to have greater control in the payment process.

As indicated above, most payment transactions today involve the transferof electronic funds. For purposes of background, the current industrypractice with respect to electronic funds payment using a paymentinstrument is best shown by referring now to FIG. 1 which is a flowdiagram illustrating a known process for purchaser payment. According toFIG. 1, a purchaser typically carries multiple forms of payment to allowthe purchaser to choose which source of funding to use to pay for agiven purchase. As is the current practice in the industry, a line ofcommunication must be made between each form of payment used by apurchaser and each source of funds via an existing computer paymentnetwork or system. This occurs for each transaction. Thus, eachtransaction may require a different form of payment, a different pointof sale (POS) terminal, a different computer payment system, a differentsource of funds, or a combination thereof. Thus, for multipletransactions, there are numerous communications and many transactionprocessing steps that must occur.

FIG. 2A is a flow diagram which expands upon the existing computerpayment system infrastructure of FIG. 1 and is an example of a credit ordebit route for a VISA or MasterCard transaction. The parties to anauthorization and a settlement VISA or MasterCard transaction typicallycomprise a purchaser, a merchant, an optional International SalesOrganization (ISO), a merchant acquirer, VISA/MasterCard, an optionalissuer processor, an issuer, and a source of funds. A series of eventsshown in FIG. 2A has to occur for each VISA/MasterCard transaction usinga VISA/MasterCard payment card used at a merchant point of sale (POS)terminal. Among the disadvantages associated with such a system is thatit requires purchasers to carry multiple payment instruments that arealways “on,” increases the risk that a payment instrument such as acredit card or a debit card will get lost or stolen which in turnincreases the risk of fraud, and does not provide the payment instrumentholder the ability to control the terms and conditions of the use of thepayment instrument at point of sale.

FIG. 2B is a flow diagram illustrating the current industry process forauthorization of a VISA/MasterCard transaction. FIG. 2C is a flowdiagram illustrating the current industry process for settlement of aVISA/MasterCard transaction. In the authorization process, as shown inFIG. 2B, a purchaser uses a VISA/MasterCard payment card to pay forgoods or services at a merchant point of sale (POS) terminal, thetransaction is captured by an ISO or a merchant acquirer. An ISO is anindependent sales organization that is a reseller of acquirer services.A merchant acquirer is typically a bank member of a card network thatcollects payments on behalf of a merchant. The transaction is thenrouted by the merchant acquirer to the computer payment network which,in this example, is VISA or MasterCard. The transaction is then routedto an issuer. The issuer is typically a bank member of a card networkthat issues network approved cards. The issuer may approve or deny atransaction based upon the presence of fraudulent activity or upon fundsavailability. The funds availability is communicatively connected to asource of funds as shown in FIG. 2A. The transaction is either approvedor declined and returned to the merchant POS terminal.

With respect to the process for settlement shown m FIG. 2C,VISA/MasterCard facilitates settlement between the merchant acquirer andissuer. The merchant acquirer then settles with the merchant. The issuerthen settles with the purchaser using the funding source that is linkedto the VISA MasterCard payment card.

The above process is known and currently occurs for each such paymenttransaction. As indicated above, there is no means for a payment holderto have direct control over the payment instrument's availability foruse because it is always “on.” There is no means to address fraudulentuse until after the occurrence of the fraud or misuse. Thus, thereremains a need for an alternative payment instrument that addressesthese enumerated concerns as well as others of the payment instrumentholder.

SUMMARY OF THE INVENTION

The present invention is directed to a computer-based network system andmethod for using a payment vehicle having an on and off function. Thesystem comprises a payment vehicle comprising an on and off function toenable or to disable the payment vehicle in the computer-based networkfor processing an electronic payment transaction. The system alsocomprises a holder of the payment vehicle and a computer paymentnetwork. The computer payment network preferably comprises a transactionengine for enabling or for disabling the payment vehicle at a request ofthe holder of the payment vehicle.

The present invention also provides for a method of using the paymentvehicle having an on and off function. The method generally comprisesreceiving a message from a payment vehicle holder to enable a paymentvehicle of the payment vehicle holder prior to a payment transaction andenabling the payment vehicle by removing a block placed on the paymentvehicle. Alternatively, the method generally comprises receiving amessage from a payment vehicle holder to disable a payment vehicle ofthe payment vehicle holder and disabling the payment vehicle by placinga block on the payment vehicle.

The method of using a payment vehicle having an on and off function alsogenerally comprises receiving a request from a user to use a paymentvehicle of a payment vehicle holder for an electronic paymenttransaction in a computer-based payment network prior to a paymenttransaction, checking to see if a block has been placed or removed bythe payment vehicle holder on the payment vehicle, and terminating theelectronic payment transaction if the block has been placed on thepayment vehicle.

There are also numerous features and functions associated with thepayment vehicle having an on and off function in accordance with thepresent invention. Many of which are described in detail herein. Furtherareas of applicability of the present invention will become apparentfrom the detailed description provided hereinafter. It should beunderstood that _(th) ^(˜) detailed description and specific examples,while indicating the preferred embodiment of the invention, are intendedfor purposes of illustration only and are not intended to limit thescope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more fully understood from thedetailed description and the accompanying drawings, which are notnecessarily to scale, wherein:

FIG. 1 is a flow diagram illustrating a known process for makingpurchaser payments with a traditional payment instrument and computernetwork payment system.

FIG. 2A is a flow diagram which expands upon the existing computerpayment system infrastructure of FIG. 1 and is an example of a credit ordebit route for a typical VISA or MasterCard transaction.

FIG. 2B is a flow diagram of the current industry process forauthorization of a VISA/MasterCard transaction using a traditionalpayment card and computer network payment system.

FIG. 2C is a flow diagram of the current industry process for settlementof a VISA/MasterCard transaction.

FIG. 3 is a flow diagram of the overall system and method of the presentinvention.

FIG. 4A is a flow diagram of the authorization process for a paymenttransaction using a payment vehicle having the on and off feature of thepresent invention.

FIG. 4B is a flow diagram illustrating the overall environment in whichthe computer-based payment system and payment vehicle of the presentinvention operates.

FIG. 4C is a flow diagram illustrating the settlement process for apayment transaction using a payment vehicle having the on and offfeature of the present invention.

DETAILED DESCRIPTION

The following detailed description of the embodiment(s) is merelyexemplary in nature and is in no way intended to limit the invention,its application, or uses.

The present invention relates to a payment vehicle having an “on” and“off” function. The “on” and “off” feature of the payment vehicle of thepresent invention permits the holder of a payment vehicle to provideinstructions as to whether to turn its payment vehicle “on” when it isready to be used and to be turned “off” to prevent use when the holderof the payment vehicle so chooses. The use to be prevented may either beof the payment vehicle holder itself or to prevent unauthorized use byanother.

The present invention provides a way in which a holder of a paymentvehicle, preferably a customer of the card issuer, can exert leverage orcontrol over its payment vehicle.

A payment vehicle, as referred to herein, refers to an instrument usedto conduct a payment transaction excluding cash. Examples of paymentvehicles suitable for use in the present invention include, but are notlimited to, a debit card, credit card, pre-paid card, stored value card,automated teller machine (ATM), wire, automated clearinghouse (ACH),online banking, online bill pay, and internet payment account. Thepayment vehicle of the present invention may be extended to other onlinepayment services or instruments.

For example, a payment vehicle holder can use a device such as apersonal data assistant (PDA) or a cell phone to send a text messagethat reads “card on” or to send a text message that reads “card off” tothe bank or other institution that issued the payment vehicle to thecardholder.

The payment vehicle holder can keep the payment vehicle “off” and thensend a text message to the payment vehicle issuer to turn it “on” forany number of reasons or at any time the holder of the payment vehicleso chooses. Likewise, a text message can be sent to turn it back “off”when done. There are any number of methods that are able to be used tonotify to turn the payment vehicle “on” and “off” within the scope ofthe present invention. A text message is just one non-limiting example.The payment vehicle holder can establish or set rules with the cardissuer as to when the card is to be turned “on” or “off” The holder ofthe payment vehicle can check card status at any time. The paymentvehicle can be set to have time-based access. For example, rules may beset by time period such as the payment vehicle holder instructs to turnthe payment vehicle off from 11 pm to 8 am daily. Another example isthat the payment vehicle can be turned on or off based upon a specifiedtransaction type such as by a merchant category code. Still yet anotherexample is that the payment vehicle holder could determine that thepayment vehicle only is “on” for gas and grocery purchases but“off” forinternet purchases, international purchases, among others. Any number ofrules could be set alone or in combination. Another example is that thepayment vehicle can be turned on or off based upon country code.

In addition, the present invention relates to a payment vehicle havingthe “on” and “off” feature such as where the payment vehicle is anonline banking account having established rules for when access isturned on and off. For example, the holder of the online banking accountcould set a rule that there can be no payments made using the onlinebanking account, for example, between 11 pm and 8 am daily.Alternatively, the online banking account can be set such that fundstatus can be viewed but funds cannot be moved or transferred.

The “on” and “off” feature could be utilized in an authorizationenvironment or in an environment where authorizations are not utilized.An important aspect to the present invention is the “on” and “off”functionality and the ability to give a payment vehicle holder who istypically a customer of a financial institution control of the paymentvehicle in a computer-based network system leveraging thatfunctionality.

The logic which is the basis for the “on” and “off” functionality in thecomputer-based network system is comprised within the payment vehicle'sprocessing environment. The following non-limiting example relates tothe processing of credit cards and debit cards although the logic isreadily applied to other types of payment vehicles.

As mentioned previously, a typical credit card transaction involves atwo-part transaction, namely authorization and settlement. Duringauthorization, the question is asked if the money or funds are there andthe question is asked if the card is valid. It can be a signature-basedtransaction or a PIN-based transaction. A pin-based transaction is atransaction in which authorization and settlement occur at same time.The method of authorization is card specific and is known in theindustry. For example, VISA has a different payment network than othercard providers. With the payment vehicle having the “on” and “off”feature of the present invention, the merchant would know that aninvalid card is turned “off” for purposes of the transaction.

Settlement processing occurs with purchases made by internet, mailorder, phone order, or card on file. Some of these go through anauthorization transaction coming in looking for settlement from amerchant. A payment vehicle having the “on” and “off” feature of thepresent invention could be used in these transactions as well as othertransactions that may involve interlink, automated teller machine (ATM),ACH, wires and others.

Referring now to the figures, FIG. 3 is a flow diagram illustrating theoverall system and method of the present invention. As shown in FIG. 3,a payment vehicle holder sends an “on” or “off” message regarding itspayment vehicle. After receipt of the message, the payment vehicle iseither disabled (i.e. turned off) by a block being placed or enabled(i.e. turned on) by a block being removed. A confirmation of whether theblock is on or off is electronically sent to the payment vehicle holder.The payment vehicle holder uses its payment vehicle to for example, makea purchase, signon to online banking, make an ATM withdraw!, make an ACHdeposit, or money transfer. It is checked to see if the block is off forthe payment vehicle. If the block is not off, the transaction ends. Ifthe block is off, the transaction proceeds through normal processing forthat respective payment vehicle.

FIG. 4A illustrates a payment vehicle having an “on” and “off” featurein accordance with the present invention for use in a computer-basedenvironment for processing electronic payment transactions. As shown inFIG. 4A, the system comprises a user, a payment vehicle, a computerpayment network comprising an “on” and “off” transaction engine, and asource of funds. Preferably, the user is the holder of the paymentvehicle; however, it is within the scope of the present invention thatsomeone other than the payment vehicle holder would use the paymentvehicle to make a purchase or to access funds. The “on” and “off”transaction engine further comprises the “on” and “off” logic todetermine whether or not the payment vehicle is enabled or disabled(i.e. “on” or “off”) prior to a payment transaction. If the paymentvehicle is “on” and a transaction is enabled (i.e. not disabled orblocked), it is a valid option and the computer payment network isconnected to the source of funds. Each user potentially has access tomultiple payment vehicles having this “on” and “off” functionality.

FIG. 4B is a flow diagram of the authorization process for a paymenttransaction using a payment vehicle having the “on” and “off” feature ofthe present invention. As shown in FIG. 4B, a purchaser uses a paymentcard to pay for goods and services at a merchant point of sale terminal.The transaction is captured by the ISO or merchant acquirer. Thetransaction is routed to VISA/Mastercard. From VISA/Mastercard, thetransaction is routed to the issuer. The “on” and “off” transactionengine of the computer payment network queries whether the payment cardis “off.” If it is “off,” the transaction is declined and returned tomerchant point of sale terminal. If the payment card is not “off,” it isfurther processed to determine if there is fraud associated with thetransaction. If there is fraud, the transaction is declined and returnedto merchant point of sale terminal. If there is no fraud, the computerpayment network checks to see if funds are available.

FIG. 4C is a flow diagram illustrating the settlement process for apayment transaction using a payment vehicle having the “on” and “off”feature of the present invention. As shown in FIG. 4C, the merchantacquirer settles with VISA/Mastercard. From VISA/Mastercard, the issuersettles with VISA/Mastercard. The “on”/“off” transaction engine querieswhether the payment card is “off.” If the payment card is not “off,” theissuer settles with the purchaser. If the payment card is “off,” theissuer does not settle with the purchaser and initiates charge back tothe card. If funds are available, the transaction is approved andreturned to merchant point of sale terminal. If funds are not available,the transaction is declined and returned to merchant point of saleterminal.

As discussed herein, a payment vehicle having the “on” and “off” featureof the present invention allows the holder of the payment vehicle toremotely enable or disable its payment vehicle. The present inventionprovides a payment vehicle holder such as a customer of a financialinstitution control over its payment vehicle through leveraging of the“on” and “off” logic that may be transmitted, for example, via textmessage, e-mail, or other electronic means. While the present inventionmay be run in a variety of settings, it is advantageous for its logic tobe run in a card processing environment.

There are numerous other features that are optionally associated with apayment vehicle having the “on” and “off” feature of the presentinvention. For example, a payment vehicle holder such as a customer of afinancial institution is able to get the latest status of his or herpayment vehicle. For example, the status may be enabled or disabled aswell as more detailed reporting. This core functionality leads toadditional features as described below.

Among the features of the present invention include time based access tothe payment vehicles. For example, the payment vehicle is enabled from xtime toy time. This may also be used for online banking access also.

A two credit/debit level authorization per transaction 1 s anotherfeature. For example, a customer will receive a communication, includingbut not limited to, a short message service (sms), a phone recording, oremail verifying that it is permissible to allow the transaction.

Another feature of the payment vehicle of the present invention providesfor the holder of the payment vehicle to refuse or stop a transactionthat exceeds a predefined amount. The user may also refuse or stop atransaction of a specific type or limit the use of the payment vehicleto transactions of a certain type or merchant category code.

Yet another feature of the payment vehicle of the present invention isconfirmation messaging. The payment vehicle holder receives acommunication, including but not limited to, a sms, a phone recording,or email verifying that the payment vehicle holder's request to turn thepayment vehicle on or off has been accomplished.

Still yet another feature of the payment vehicle of the presentinvention is vendor messaging. For example, when a person attempts touse a payment vehicle that has been turned off, the vendor receives amessage informing him or her that the card is rejected as it is turnedoff.

It is within the scope of the present invention that this “on” and “off”feature associated with a payment vehicle is applicable to both existingand new customers, for example, of an institution such as a financialinstitution that is a card issuer. A customer enrolls for such a programand his/her account is marked accordingly. A customer selects a cardaccount and agrees to use a card having the “on” and “off” feature. Acustomer then receives notification of enrollment, instructions, andinitial card status. Such functionality is comprised, for example, in acard on/off transaction engine.

Thus, the payment vehicle of the present invention is advantageous formany reasons including because it provides additional security forpayment vehicles. The payment vehicle of the present invention havingthe “on” and “off” feature permits customers to easily manage thesecurity of their payment vehicles by switching them off when not inuse. With the present invention, it is possible to disable the paymentvehicle, such as a credit card, for safety or other purposes wheneverthe holder of a payment vehicle so chooses. For example, messaging isaccomplished by sms or email.

Another advantage of the payment vehicle and method of the presentinvention is that it enhances loyalty through appreciation for theadditional security, flexibility, and control that it provides consumersover their payment vehicles.

It will therefore be readily understood by those persons skilled in theart that the present invention is susceptible of broad utility andapplication. Many embodiments and adaptations of the present inventionother than those herein described, as well as many variations,modifications and equivalent arrangements, will be apparent from orreasonably suggested by the present invention and the foregoingdescription thereof, without departing from the substance or scope ofthe present invention. Accordingly, while the present invention has beendescribed herein in detail in relation to its preferred embodiment, itis to be understood that this disclosure is only illustrative andexemplary of the present invention and is made merely for purposes ofproviding a full and enabling disclosure of the invention. The foregoingdisclosure is not intended or to be construed to limit the presentinvention or otherwise to exclude any such other embodiments,adaptations, variations, modifications and equivalent arrangements.

What is claimed is:
 1. A financial institution computing systemassociated with a financial institution comprising a transaction engineconfigured to cause the financial institution computing system to:receive, from a user device associated with a user, a message includinga rule that the user wishes to be associated with a payment vehicle ofthe user, the rule including criteria against which future transactionauthorization requests are to be assessed; in response to receiving themessage, update logic associated with the payment vehicle stored at thefinancial institution computing system to incorporate the rule, whereinthe logic associated with the payment vehicle includes a user-preferredactivation status of the payment vehicle, wherein the user-preferredactivation status of the payment vehicle may be updated by the user;receive, from a merchant computing system associated with a merchant, afirst transaction authorization request; determine that the firsttransaction authorization request is inconsistent with the rule; and inresponse to the determination that the first transaction authorizationrequest is inconsistent with the rule: provide a first indication thatthe first transaction authorization request is inconsistent with therule to the merchant, wherein the first indication contains informationconcerning the rule; and provide a second indication that the firsttransaction authorization request is inconsistent with the rule to theuser device.
 2. The financial institution computing system of claim 1,wherein the message comprises an e-mail.
 3. The financial institutioncomputing system of claim 1, wherein the message comprises a textmessage.
 4. The financial institution computing system of claim 1,wherein the transaction engine is further configured to cause thefinancial institution computing system to: receive, from the userdevice, a request for information regarding the logic associated withthe payment vehicle; and in response to receiving the request, provideinformation regarding the logic associated with the payment vehicle tothe user device.
 5. The financial institution computing system of claim1, wherein the rule associated with the payment vehicle places thepayment vehicle into an inactivated state.
 6. The financial institutioncomputing system of claim 1, wherein the rule associated with thepayment vehicle inactivates the payment vehicle for transactions abovean amount.
 7. The financial institution computing system of claim 1,wherein the rule associated with the payment vehicle inactivates thepayment vehicle for transactions at a set of merchants.
 8. The financialinstitution computing system of claim 1, wherein the rule associatedwith the payment vehicle inactivates the payment vehicle fortransactions occurring within a specified time interval.
 9. Thefinancial institution computing system of claim 1, wherein thetransaction engine is further configured to cause the financialinstitution computing system to, in response to updating the logicassociated with the payment vehicle, provide the user with confirmationof updating the logic.
 10. The financial institution computing system ofclaim 1, wherein the transaction engine is further configured to causethe financial institution computing system to: receive a secondtransaction authorization request; determine that the second transactionauthorization request is consistent with the rule; and in response tothe determination that the second authorization request is consistentwith the rule, provide an indication that the second transactionauthorization request is consistent with the rule to the user deviceprior to authorizing the transaction.
 11. A computer-implemented method,comprising: receiving, by a financial institution computing system, froma user device associated with a user, a message including a rule thatthe user wishes to be associated with a payment vehicle of the user, therule including criteria against which future transaction authorizationrequests are to be assessed; in response to receiving the message,updating, by the financial institution computing system, logicassociated with the payment vehicle stored at the financial institutioncomputing system to incorporate the rule, wherein the logic associatedwith the payment vehicle includes a user-preferred activation status ofthe payment vehicle, wherein the user-preferred activation status of thepayment vehicle may be updated by the user; receiving, by the financialinstitution computing system, from a merchant computing systemassociated with a merchant, a first transaction authorization request;determining, by the financial institution computing system, that thefirst transaction authorization request is inconsistent with the rule;and in response to the determination that the first transactionauthorization request is inconsistent with the rule: providing, by thefinancial institution computing system, a first indication of that thefirst transaction authorization request is inconsistent with the rule tothe merchant, wherein the first indication contains informationconcerning the rule; and providing, by the financial institutioncomputing system, a second indication that the first transactionauthorization request is inconsistent with the rule to the user device.12. The computer-implemented method of claim 11, wherein the messagecomprises an e-mail.
 13. The computer-implemented method of claim 11,wherein the message comprises a text message.
 14. Thecomputer-implemented method of claim 11, further comprising: receiving,by the financial institution computing system, from the user device, arequest for information regarding the logic associated with the paymentvehicle; and in response to receiving the request, providing, by thefinancial institution computing system, information regarding the logicassociated with the payment vehicle regarding the user device.
 15. Thecomputer-implemented method of claim 11, wherein the rule associatedwith the payment vehicle places the payment vehicle into an inactivatedstate.
 16. The computer-implemented method of claim 11, wherein the ruleassociated with the payment vehicle inactivates the payment vehicle fortransactions above an amount.
 17. The computer-implemented method ofclaim 11, wherein the rule associated with the payment vehicleinactivates the payment vehicle for transactions at a set of merchants.18. The computer-implemented method of claim 11, wherein the ruleassociated with the payment vehicle inactivates the payment vehicle fortransactions occurring within a specified time interval.
 19. Thecomputer-implemented method of claim 11, further comprising, in responseto updating the logic associated with the payment vehicle, providing, bythe financial institution computing system, the user with confirmationof updating the logic.
 20. The computer-implemented method of claim 11,further comprising: receiving, by the financial institution computingsystem, a second transaction authorization request; determining, by thefinancial institution computing system, that the second transactionauthorization request is consistent with the rule; and in response tothe determination that the second authorization request is consistentwith the rule, providing, by the financial institution computing system,an indication that the second transaction authorization request isconsistent with the rule to the user device prior to authorizing thetransaction.